Optimization of handover procedures in gprs

ABSTRACT

The present invention discloses a method related to Attach procedures and Routing Area Update (RAU) procedures in packet switched cellular networks, in particular GPRS and UMTS networks. When an MS roams from a routing area covered by several SGSNs in an SGSN pool into a routing area covered by one SGSN (new SGSN) outside the pool, the roaming request will be sent from the new SGSN to a default SGSN, which for the new SGSN is believed to be the old SGSN. The default SGSN will, unless it itself is the old SGSN, relay the roaming request to the SGSN (old SGSN) previously serving the MS. To avoid that the default SGSN has to monitor for a response of the request, and thereby occupying resources in the default SGSN, the default SGSN inserts (or when possible, leave unchanged) the address of the new SGSN in the request. The response of the request will therefore be transmitted directly from the old SGSN to the new SGSN and not via the default SGSN as described in the existing technical specifications.

FIELD OF THE INVENTION

[0001] The present invention is related to Attach procedures and RoutingArea Update (RAU) procedures in packet switched cellular networkswherein several service nodes are connected to the same radio network.The invention will be described in the terminology of the UMTS and GPRSnetworks, well known for a person skilled in the art, and referenceswill be made to the 3GPP (3^(rd) Generation Partnership Project)Technical Specification 29.060 and 23.060.

BACKGROUND OF THE INVENTION

[0002] A packet switched cellular network such as GPRS or UMTS,comprises several nodes handling traffic flow and signalling within andin and out of the network. One such node is the SGSN node similar to thefunctionality of MSC/VLR of GSM. An SGSN is responsible for detectingMSs in its geographical area, registering them and keeping track oftheir movements within the routing area.

[0003] Until now, a radio network node is connected towards one and onlyone SGSN, as shown in FIG. 1. A radio network node is either an RNC(Radio Network Controller) or a BSC (Base Station Controller).

[0004] 3GPP (3^(rd) Generation Partnership Project), which is astandardisation body for 3rd generation mobile systems, is for the timebeing developing a concept where a radio network node is allowed to beconnected towards several SGSNs, as shown in FIG. 2. The idea is toplace several SGSNs in a pool, and that all of them cover the samegeographical area, which then can be bigger than the area previouslycovered by one SGSN. As long as an MS is located within the pool area,the MS will be attached to the same SGSN. This has several advantages,e.g. better load sharing between SGSNs, reduced signalling in the corenetwork, improved service performance, better scalability and easierupgrade of the nodes. Also, it opens up for several operators to sharethe radio network, or parts of it, while still having separate SGSNs.This is especially useful for operators having a 2G (2^(nd) Generation)network, but who did not receive licences for a 3G (3^(rd) Generation)network, or vice versa. The sharing of radio network is also useful foroperators who want to cut costs.

[0005] The dotted lines in FIG. 2 shows what is new with the poolconcept, i.e. that an RNC or a BSC can be connected to two or moreSGSNs.

[0006] When an MS is getting attached to an SGSN, the SGSN will allocatea P-TMSI (Packet-Temporary Mobile Subscriber Identity) value to the MS.In a pool concept, each of the SGSNs within the pool will have their ownunique range of P-TMSI values. If the value range of each of the SGSNsis given to (known by) the surrounding nodes (BSCs, RNCs or otherSGSNs), then these surrounding nodes will know to which of the SGSNs theMS is (or was) attached.

[0007] In some cases, however, the surrounding nodes will not know theP-TMSI ranges of each of the SGSNs in a pool. One example of this iswhen an MS roams into an area covered by an SGSN that is not aware ofthe pool. In this case, the new SGSN cannot uniquely identify the oldSGSN to which the MS was attached. Another example is when theconfiguration effort is minimised so that the nodes outside an SGSN pooldo not know about the internal structure of the SGSN pool. The solutionto this problem is that one of the SGSNs in a pool, referred to as thedefault SGSN, will be appointed as a representative for the routing areacovered by the pool. A new SGSN outside the mentioned routing area willlook at the old Routing Area id of the MS in the received request(routing area update or attach), as usual, to determine which SGSN tocontact. The default SGSN will be associated with that routing area id,and the new SGSN will therefore send a request to the default SGSNwithout being aware of the pool. The default SGSN will know the P-TMSIranges of each of the SGSNs within the pool. Thus, the default SGSN canlook at the received P-TMSI parameter, or the TLLI (Temporary LogicalLink Identity) parameter that is based on the P-TMSI parameter if thisis received instead, and forward the message to the correct SGSN. Thisaspect is already discussed within 3GPP (3^(rd) Generation PartnershipProject), and it is shown in FIG. 3 for the Attach procedure and in FIG.4 for the Routing Area Update procedure. FIG. 3 and FIG. 4 show how thebeginning of these two procedures must be done when using the existingprocedures defined in 3GPP TS (Technical Specification) 29.060. Said TSdefines the messages that are sent between two SGSNs, and the messagesthat are sent between an SGSN and a GGSN (Gateway GPRS Support Node,where GPRS stands for General Packet Radio Service).

[0008] Referring to FIG. 3, in step 1, the MS that previously waslocated in an SGSN pool area covered by the Default SGSN and the OldSGSN, roams into an area covered by the New SGSN, and sends an AttachRequest message to the New SGSN. The New SGSN looks at the received ‘oldRouting Area’ to find which SGSN to contact, and in this case it is theDefault SGSN.

[0009] In step 2, the New SGSN sends an Identification Request messageto the Default SGSN. The Default SGSN looks at the old P-TMSI todetermine which SGSN within the pool handled the MS before it wasroaming. The P-TMSI in this example belongs to the Old SGSN.

[0010] In step 3, the Default SGSN relays the Identification Requestmessage to the Old SGSN. The Default SGSN must also keep information onfrom which SGSN it received the Identification Request message (i.e. theNew SGSN) to be able to send the response to the correct SGSN.

[0011] In step 4, the Old SGSN returns an Identification Responsemessage to the Default SGSN.

[0012] In step 5, the Default SGSN relays the Identification Responsemessage to the New SGSN, and this is based on the information stored instep 3.

[0013] Now referring to FIG. 4, in step 1, the MS that previously waslocated in an SGSN pool area covered by the Default SGSN and the OldSGSN, roams into an area covered by the New SGSN, and sends a RoutingArea Update Request message to the New SGSN. The New SGSN looks at thereceived ‘old Routing Area’ to find which SGSN to contact, and in thisexample it is the Default SGSN.

[0014] In step 2, the New SGSN sends an SGSN Context Request message tothe Default SGSN. The Default SGSN looks at the old P-TMSI, or the TLLI(Temporary Logical Link Identity) parameter, which is based on theP-TMSI parameter if this is received instead, to determine which SGSNwithin the pool handled the MS before it was roaming. The P-TMSI, or theTLLI, in this example belongs to the Old SGSN.

[0015] In step 3, the Default SGSN relays the SGSN Context Requestmessage to the Old SGSN. Since the Default SGSN must monitor theresponse for this message in the way the GTP (GPRS Tunnelling Protocol)protocol is defined today, the Default SGSN must change the ‘IP address’and the ‘TEID’ (Tunnel Endpoint IDentifier) for where it wants toreceive the response message. The Default SGSN must also keepinformation on from which SGSN it received the SGSN Context Requestmessage (i.e. the New SGSN) to be able to send the response to thecorrect SGSN.

[0016] In step 4, the Old SGSN returns an SGSN Context Response messageto the Default SGSN.

[0017] In step 5, the Default SGSN relays the SGSN Context Responsemessage to the New SGSN, and this is based on the information stored instep 3.

[0018] The problem with the sequences in FIG. 3 and FIG. 4 is that theIdentification Response message and the SGSN Context Response messagemust be sent through the Default SGSN, as shown in step 4. This meansthat the Default SGSN must keep some state information for this MS aswell as some information on which SGSN it received the IdentificationRequest message or SGSN Context Request message from, as described instep 3 for FIG. 3 and FIG. 4. This means that unnecessary resources areoccupied and unnecessary processor load is generated in the DefaultSGSN. Also, this will slightly increase the time needed to perform ahandover.

[0019] The concept of placing several SGSNs in a pool is not previouslyknown in GSM (Global System for Mobile Communication). Theabove-described handover problems are new problems that appeared in thecurrent standardisation of the pool concept within 3GPP, and thereforethere are no known solutions to the problem.

SUMMARY OF THE INVENTION

[0020] It is an object of the present invention to provide anarrangement that eliminates the drawbacks described above. The featuresdefined in the claims enclosed characterize this method.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to make the invention more readily understandable, thediscussion that follows will refer to the accompanying drawings.

[0022]FIG. 1 shows the relationship between the nodes in a GPRS/UMTSnetwork according to common practice,

[0023]FIG. 2 shows the relationship between the nodes in a GPRS/UMTSnetwork according to the pool concept introduced in a new release of the3GPP standard (Release 5),

[0024]FIG. 3 shows an Attach Procedure when an MS attaches a standaloneSGSN (or an SGSN in another pool) after having been attached to a SGSNin a pool,

[0025]FIG. 4 shows a Routing Area Procedure when an MS roams from anSGSN in a pool to a standalone SGSN (or an SGSN in another pool),

[0026]FIG. 5 shows an Attach Procedure according to the presentinvention when an MS attaches a standalone SGSN (or an SGSN in anotherpool) after having been attached to an SGSN in a pool,

[0027]FIG. 6 shows a Routing Area Procedure according to the presentinvention when an MS roams from an SGSN in a pool to a standalone SGSN(or an SGSN in another pool).

DESCRIPTION OF THE PRESENT INVENTION

[0028] Two embodiments of the present invention will now be describedwith reference to FIG. 5 and FIG. 6, respectively. The first embodimentdescribes two alternative solutions addressing an attach procedure,while the second embodiment describes a solution for the routing areaupdate procedure.

[0029] In step 1 of FIG. 5, the MS that previously was located in anSGSN pool area covered by at least the Default SGSN and the Old SGSN,roams into an area outside the pool covered by the New SGSN, and sendsan Attach Request message to the New SGSN. The New SGSN looks at thereceived ‘old Routing Area’ to find which SGSN to contact, and in thisexample it is the Default SGSN.

[0030] In step 2, the New SGSN sends an Identification Request messageto the Default SGSN. The Default SGSN looks at the old P-TMSI todetermine which SGSN within the pool handled the MS before it wasroaming. The P-TMSI in this example belongs to the Old SGSN.

[0031] In step 3, the Default SGSN relays the Identification Requestmessage to the Old SGSN. This message should now include the address ofthe New SGSN, and the Default SGSN should not monitor the responsemessage from the Old SGSN.

[0032] In step 4, the Old SGSN returns an Identification Responsemessage directly to the New SGSN.

[0033] According to the first embodiment of the present invention, thenew functionality for this attached sequence is as follows:

[0034] The Default SGSN should include the address of the New SGSN whenforwarding the Identification Request message to the Old SGSN.

[0035] This may be done in two ways. One alternative is that the DefaultSGSN leaves the ‘Source IP Address’ from the IP (Internet Protocol)layer of the Identification Request message unchanged when relaying theIdentification Request message to the old SGSN. Normally, according tothe Internet Protocol, this address would have been the address of thesender, i.e. the default SGSN, but by instructing the default SGSN toleave the address of the new SGSN in the ‘Source IP Address’ fieldunchanged when relaying the Identification Request message to the oldSGSN, the old SGSN would think that the message was transmitted directlyfrom the new SGSN, and return an Identification Response to the newSGSN.

[0036] A second and preferred alternative is that the Default SGSNinserts the ‘Source IP Address’ from the IP layer (or ‘SGSN Address’) asa parameter in the GTP (GPRS Tunnelling Protocol) part of theIdentification Request message. The GTP is described in 3GGP TS 29.060,and is a protocol describing signalling messages sent between SGSNs andsignalling messages sent between an SGSN and a GGSN. Now, if the OldSGSN receives the ‘Source IP Address’ (or ‘SGSN Address’) as a parameterin the GTP part of the Identification Request message, this IP addressshall then be used when sending the Identification Response message.Consequently, in this alternative, the Old SGSN should not use the‘Source IP Address’ from the IP layer when sending the IdentificationResponse message, even though this is the normal behaviour.

[0037] In both cases, the Default SGSN does not have to monitor theIdentification Response message from the Old SGSN. (The reason for whyan SGSN sending an Identification Request message wants to monitor theIdentification Response message is in case re-transmission of theIdentification Request message is needed). Also, there is no need forthe default SGSN to store any state information about the MS or theidentity of the new SGSN.

[0038]FIG. 6 shows the message flow according to the second embodimentof the present invention. In step 1, the MS that previously was locatedin an SGSN pool area covered by the Default SGSN and the Old SGSN, roamsinto an area covered by the New SGSN, and sends a Routing Area UpdateRequest message to the New SGSN. The New SGSN looks at the received ‘oldRouting Area’ to find which SGSN to contact, and in this example it isthe Default SGSN.

[0039] In step 2, the New SGSN sends an SGSN Context Request message tothe Default SGSN. The Default SGSN looks at the old P-TMSI, or the TLLIparameter, which is based on the P-TMSI parameter if this is receivedinstead, to determine which SGSN within the pool handled the MS beforeit was roaming. The P-TMSI, or TLLI, in this example belongs to the OldSGSN.

[0040] In step 3, the Default SGSN relays the SGSN Context Requestmessage to the Old SGSN. This message should include the address of theNew SGSN (both ‘TEID’ and ‘SGSN IP Address’) within the GTP part of themessage, and this is already possible in the existing message.

[0041] In step 4, the Old SGSN returns an SGSN Context Response messagedirectly to the New SGSN.

[0042] According to the second embodiment of the present invention, thenew functionality for this routing area update sequence is as follows:

[0043] The Default SGSN should include the address of the New SGSN (both‘TEID’ and ‘SGSN IP Address’) when relaying the SGSN Context Requestmessage to the Old SGSN in the GTP part of the SGSN Context Requestmessage. This means that the Default SGSN should not change this part ofthe message when receiving it from the New SGSN.

[0044] The result also of this embodiment is that The Default SGSN doesnot have to monitor the SGSN Context Response message from the Old SGSN,and there will be no need for the default SGSN to store any stateinformation about the MS or the identity of the new SGSN.

[0045] The present invention gives the opportunity of the Old SGSN tosend the Identification Response message and the SGSN Context Responsemessage directly to the New SGSN, as shown in FIG. 5 and in FIG. 6, sothat resources are not unnecessarily occupied in the Default SGSN, and aminimum of processing capacity is required. Also, this will slightlydecrease the time needed to perform a handover, as one signalling stepwill be avoided

[0046] The present invention is applicable for both GSM (Global Systemfor Mobile Communication) GPRS and UMTS (Universal MobileTelecommunication System) GPRS.

1. Method in a packet switched cellular network including at least onepool of first service nodes being able to serve terminals in the samearea, and at least one second service node not included in the pool ofsaid first service nodes, wherein the terminals are allocated onetemporary identity by each of said at least one second service node, andwherein the terminals within an area covered by first service nodes inthe pool are allocated one temporary identity from an identity rangeunique for said pool of first service nodes, comprising the steps of: a)in response to a new service node associated with said at least onesecond service node receiving a first request message from one of theterminals previously served by an old service node associated with thepool of said first service nodes, sending a second request message fromthe new service node to a default service node also associated with thepool of said first service nodes and including a temporary identity ofthe terminal allocated by the old service node, b) in the defaultservice node, identifying the old service node by means of the temporaryidentity included in the received second request message, c) includingan address of the new serving node in the second request message andrelaying it to the old service node, d) in the old service node,returning a response message to the new service node by addressing theresponse message by means of the address included in the received secondrequest message.
 2. Method according to claim 1, wherein that the packetswitched cellular network is a GPRS network and the serving nodes areSGSN nodes.
 3. Method according to claim 2, wherein that the firstrequest message is an Attach Request, the second request message is anIdentification Request and the response message is an IdentificationResponse.
 4. Method according to claim 2, wherein that the first requestmessage is a Routing Area Update Request, the second request message isan SGSN Context Request and the response message is an SGSN ContextResponse.
 5. Method according to claim 2 wherein that the temporaryidentities are P-TMSIs.
 6. Method according to claim 2 wherein that thetemporary identities are TLLIs.
 7. Method according to claim 2 whereinthat the inclusion of the address of the new serving node in the secondrequest message in step c) is carried through in the default servingnode by leaving the source IP Address of the new serving node in thesecond request message unchanged when relaying the second requestmessage to the old serving node.
 8. Method according to claim 2 whereinthat the inclusion of the address of the new serving node in the secondrequest message in step c) is carried through in the default servingnode by inserting the Source IP Address from the IP layer of thereceived second request message as a parameter in the GTP part of thesecond request message.
 9. Method according to claim 8, wherein that incase the inclusion of the address of the new serving node in the secondrequest message in step c) is carried through by inserting a Source IPAddress as a parameter in the GTP part of the second request message,the old service node uses this Source IP Address as the destination IPaddress of the response message mentioned in step d).
 10. Methodaccording to claim 7 wherein that the second request message is anIdentification Request message, and the response message is anIdentification Response message.
 11. Method according to claim 2 whereinthat the inclusion of the address of the new serving node in the secondrequest message in step c) is carried through in the default servingnode by leaving unchanged the TEID and the SGSN IP Address of the newSGSN in the GTP part of the second request message.
 12. Method accordingto claim 11, wherein that the second request message is an SGSN ContextRequest message.
 13. Method according to claim 2 wherein that thedefault service node does not supervise the response message that theold service node will return as a result of the second request messagebeing relayed in step c).
 14. A system in a packet switched cellularnetwork including at least one pool of first service nodes being able toserve terminals in the same area, and at least one second service nodenot included in the pool of said first service nodes, wherein theterminals are allocated one temporary identity by each of said at leastone second service node, and wherein the terminals within an areacovered by first service nodes in the pool are allocated one temporaryidentity from an identity range unique for said pool of first servicenodes, comprising the steps of: a) in response to a new service nodeassociated with said at least one second service node receiving a firstrequest message from one of the terminals previously served by an oldservice node associated with the pool of said first service nodes, meansfor sending a second request message from the new service node to adefault service node also associated with the pool of said first servicenodes and including a temporary identity of the terminal allocated bythe old service node, b) in the default service node, means foridentifying the old service node by means of the temporary identityincluded in the received second request message, c) means for includingan address of the new serving node in the second request message andrelaying it to the old service node, d) in the old service node, meansfor returning a response message to the new service node by addressingthe response message by means of the address included in the receivedsecond request message.
 15. The system of claim 14 wherein that thepacket switched cellular network is a GPRS network and the serving nodesare SGSN nodes.
 16. The system of claim 15, wherein that the firstrequest message is an Attach Request, the second request message is anIdentification Request and the response message is an IdentificationResponse.
 17. The system of claim 15 wherein that the first requestmessage is a Routing Area Update Request, the second request message isan SGSN Context Request and the response message is an SGSN ContextResponse.
 18. The system of claim 15 wherein that the temporaryidentities are P-TMSIs.
 19. The system of claim 15 wherein that thetemporary identities are TLLIs.
 20. The system of claim 15 wherein saidmeans for including the address of the new serving node in the secondrequest message leaves the source IP Address of the new serving node inthe second request message unchanged when relaying the second requestmessage to the old serving node.
 21. The system of claim 15 wherein saidmeans for including the address of the new serving node in the secondrequest message inserts the Source IP Address from the IP layer of thereceived second request message as a parameter in the GTP part of thesecond request message.
 22. The system of claim 21, wherein the oldservice node uses this Source IP Address as the destination IP addressof the response message.
 23. The system of claim 15 wherein said meansfor including the address of the new serving node in the second requestmessage in the default serving node leaves unchanged the TEID and theSGSN IP Address of the new SGSN in the GTP part of the second requestmessage.
 24. The system of claim 23, wherein that the second requestmessage is an SGSN Context Request message.